Template-based software discovery and management in virtual desktop infrastructure (VDI) environments

ABSTRACT

A technique to manage software licensing in an environment that provides virtual desktop infrastructure (VDI). A license manager is configured to receive first information identifying software applications associated with a virtual machine template used in the infrastructure, as well as second information that a user has logged into the VDI from a client device, thereby creating a VDI session. For a particular time period of interest, the license manager calculates software application usage information from the first and second information. Preferably, the software application usage information represents an application count that is based on the user and the client device “pair” when the user has the VDI session during at least some portion of the time period. The software application usage information is provided to one or more other computing systems to take a given action, such as tracking, managing, auditing, enforcing and accounting for software usage in the VDI environment.

BACKGROUND OF THE INVENTION Technical Field

This disclosure relates generally to managing applications in a “cloud”compute environment.

Background of the Related Art

A popular information technology (IT) delivery model is cloud computing,by which shared resources, software and information are provided overthe Internet to computers and other devices on-demand. Cloud computingcan significantly reduce IT costs and complexities while improvingworkload optimization and service delivery. With this approach, anapplication instance can be hosted and made available fromInternet-based resources that are accessible through a conventional Webbrowser or mobile application over HTTP. Cloud compute resources aretypically housed in large server farms that run one or more networkapplications, typically using a virtualized architecture whereinapplications run inside virtual servers, or so-called “virtual machines”(VMs), that are mapped onto physical servers in a data center facility.The virtual machines typically run on top of a hypervisor, which is acontrol program that allocates physical resources to the virtualmachines.

Software as a Service (SaaS) refers to the capability provided to theconsumer is to use a provider's applications running on a cloudinfrastructure. SaaS applications are accessible from various clientdevices through a thin client interface such as a web browser. In thismodel, typically the consumer does not manage or control the underlyingcloud infrastructure including network, servers, operating systems,storage, or even individual application capabilities.

One common application class that has been increasingly deployed in thecloud is desktop virtualization. A virtual desktop infrastructure (VDI)typically provides a stateless thin client to the user while hosting theprocessing and storage resource in a remote virtual machine. In thisenvironment, a core component is a central VDI server that manages apool of computers (physical or virtual). The virtual machines may beexisting already, or they may be spawned on-demand. The user (accessingfrom remote location) has a device, such as a computer, a terminal, amobile device, or the like) with a VDI client installed. The clientconnects to the VDI server, which in turn affords the user remote accessto a desktop of one of the computers in the pool. The user may then useone or more applications that are installed on the machine.

In this operating scenario, and for security, compliance or otherbusiness requirements, the cloud provider needs to monitor applicationusage, preferably by way of an “install-based” metric of applicationlicensing wherein all applications that are installed (i.e., availableto the user) are counted as being used. Known solutions, however, havenot adequately addressed such software license consumption monitoring inthis context. In part, this is a consequence of the fact that thelifetime of the virtual machines being managed by the VDI server can bevery short (e.g., hours, or even minutes). Also, it is well-known thatdesktops are characterized by long periods of inactivity (i.e.,idleness), during which virtual machines may be down-sized to consume aminimal amount of resources required for the desktop. Traditionalapproaches to monitoring license usage in this operating environment areunsatisfactory.

The technique of this disclosure addresses the need.

BRIEF SUMMARY

This disclosure provides a technique to manage software licensing in acloud (or other network-accessible) computing environment and, inparticular, an environment that provides virtual desktop infrastructure(VDI). Typically, the VDI infrastructure comprising a VDI server thatmanages a pool of virtual machines. According to one embodiment, alicense manager is provided to facilitate preferably “install-based”metrics for application license management. To this end, the licensemanager is configured to receive first information identifying one ormore software applications associated with a virtual machine templateused in the virtual desktop infrastructure. The license manager alsoreceives second information that a user has logged into the virtualdesktop infrastructure from a client device, thereby creating a VDIsession, the session being associated with a virtual machine template.For a particular time period of interest, the license manager determinessoftware application usage information from the first and secondinformation. Preferably, the software application usage information isassociated with a licensing model that defines a usage metric based atleast in part on the user having the session during at least someportion of the time period. When an “install-based” licensing model isused, the usage metric represents an application count that is based ona user and client device “pairing” when the user has the VDI sessionduring at least some portion of the time period. The softwareapplication usage information is then provided to one or more othercomputing systems to take a given action, such as tracking, managing,auditing, enforcing and accounting for software usage in the VDIenvironment.

The foregoing has outlined some of the more pertinent features of thedisclosed subject matter. These features should be construed to bemerely illustrative. Many other beneficial results can be attained byapplying the disclosed subject matter in a different manner or bymodifying the invention as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary block diagram of a distributed dataprocessing environment in which exemplary aspects of the illustrativeembodiments may be implemented;

FIG. 2 is an exemplary block diagram of a data processing system inwhich exemplary aspects of the illustrative embodiments may beimplemented;

FIG. 3 illustrates an exemplary cloud computing architecture in whichthe disclosed subject matter may be implemented;

FIG. 4 depicts an exemplary data center in which the techniques of thisdisclosure may be implemented;

FIG. 5 illustrates an exemplary operating environment that includes alicense management system according to this disclosure; and

FIG. 6 depicts a representative process flow describing an operation ofthe license management system.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

With reference now to the drawings and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments of the disclosure may beimplemented. It should be appreciated that FIGS. 1-2 are only exemplaryand are not intended to assert or imply any limitation with regard tothe environments in which aspects or embodiments of the disclosedsubject matter may be implemented. Many modifications to the depictedenvironments may be made without departing from the spirit and scope ofthe disclosed subject matter.

Client-Server Technologies

With reference now to the drawings, FIG. 1 depicts a pictorialrepresentation of an exemplary distributed data processing system inwhich aspects of the illustrative embodiments may be implemented.Distributed data processing system 100 may include a network ofcomputers in which aspects of the illustrative embodiments may beimplemented. The distributed data processing system 100 contains atleast one network 102, which is the medium used to provide communicationlinks between various devices and computers connected together withindistributed data processing system 100. The network 102 may includeconnections, such as wire, wireless communication links, or fiber opticcables.

In the depicted example, server 104 and server 106 are connected tonetwork 102 along with storage unit 108. In addition, clients 110, 112,and 114 are also connected to network 102. These clients 110, 112, and114 may be, for example, personal computers, network computers, or thelike. In the depicted example, server 104 provides data, such as bootfiles, operating system images, and applications to the clients 110,112, and 114. Clients 110, 112, and 114 are clients to server 104 in thedepicted example. Distributed data processing system 100 may includeadditional servers, clients, and other devices not shown.

In the depicted example, distributed data processing system 100 is theInternet with network 102 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, the distributed data processing system 100 may also beimplemented to include a number of different types of networks, such asfor example, an intranet, a local area network (LAN), a wide areanetwork (WAN), or the like. As stated above, FIG. 1 is intended as anexample, not as an architectural limitation for different embodiments ofthe disclosed subject matter, and therefore, the particular elementsshown in FIG. 1 should not be considered limiting with regard to theenvironments in which the illustrative embodiments of the presentinvention may be implemented.

With reference now to FIG. 2, a block diagram of an exemplary dataprocessing system is shown in which aspects of the illustrativeembodiments may be implemented. Data processing system 200 is an exampleof a computer, such as client 110 in FIG. 1, in which computer usablecode or instructions implementing the processes for illustrativeembodiments of the disclosure may be located.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which illustrative embodiments may be implemented.Data processing system 200 is an example of a computer, such as server104 or client 110 in FIG. 1, in which computer-usable program code orinstructions implementing the processes may be located for theillustrative embodiments. In this illustrative example, data processingsystem 200 includes communications fabric 202, which providescommunications between processor unit 204, memory 206, persistentstorage 208, communications unit 210, input/output (I/O) unit 212, anddisplay 214.

Processor unit 204 serves to execute instructions for software that maybe loaded into memory 206. Processor unit 204 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 204 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 204 may be a symmetricmulti-processor (SMP) system containing multiple processors of the sametype.

Memory 206 and persistent storage 208 are examples of storage devices. Astorage device is any piece of hardware that is capable of storinginformation either on a temporary basis and/or a permanent basis. Memory206, in these examples, may be, for example, a random access memory orany other suitable volatile or non-volatile storage device. Persistentstorage 208 may take various forms depending on the particularimplementation. For example, persistent storage 208 may contain one ormore components or devices. For example, persistent storage 208 may be ahard drive, a flash memory, a rewritable optical disk, a rewritablemagnetic tape, or some combination of the above. The media used bypersistent storage 208 also may be removable. For example, a removablehard drive may be used for persistent storage 208.

Communications unit 210, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 210 is a network interface card. Communications unit210 may provide communications through the use of either or bothphysical and wireless communications links.

Input/output unit 212 allows for input and output of data with otherdevices that may be connected to data processing system 200. Forexample, input/output unit 212 may provide a connection for user inputthrough a keyboard and mouse. Further, input/output unit 212 may sendoutput to a printer. Display 214 provides a mechanism to displayinformation to a user.

Instructions for the operating system and applications or programs arelocated on persistent storage 208. These instructions may be loaded intomemory 206 for execution by processor unit 204. The processes of thedifferent embodiments may be performed by processor unit 204 usingcomputer implemented instructions, which may be located in a memory,such as memory 206. These instructions are referred to as program code,computer-usable program code, or computer-readable program code that maybe read and executed by a processor in processor unit 204. The programcode in the different embodiments may be embodied on different physicalor tangible computer-readable media, such as memory 206 or persistentstorage 208.

Program code 216 is located in a functional form on computer-readablemedia 218 that is selectively removable and may be loaded onto ortransferred to data processing system 200 for execution by processorunit 204. Program code 216 and computer-readable media 218 form computerprogram product 220 in these examples. In one example, computer-readablemedia 218 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 208 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 208. Ina tangible form, computer-readable media 218 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 200. The tangibleform of computer-readable media 218 is also referred to ascomputer-recordable storage media. In some instances,computer-recordable media 218 may not be removable.

Alternatively, program code 216 may be transferred to data processingsystem 200 from computer-readable media 218 through a communicationslink to communications unit 210 and/or through a connection toinput/output unit 212. The communications link and/or the connection maybe physical or wireless in the illustrative examples. Thecomputer-readable media also may take the form of non-tangible media,such as communications links or wireless transmissions containing theprogram code. The different components illustrated for data processingsystem 200 are not meant to provide architectural limitations to themanner in which different embodiments may be implemented. The differentillustrative embodiments may be implemented in a data processing systemincluding components in addition to or in place of those illustrated fordata processing system 200. Other components shown in FIG. 2 can bevaried from the illustrative examples shown. As one example, a storagedevice in data processing system 200 is any hardware apparatus that maystore data. Memory 206, persistent storage 208, and computer-readablemedia 218 are examples of storage devices in a tangible form.

In another example, a bus system may be used to implement communicationsfabric 202 and may be comprised of one or more buses, such as a systembus or an input/output bus. Of course, the bus system may be implementedusing any suitable type of architecture that provides for a transfer ofdata between different components or devices attached to the bus system.Additionally, a communications unit may include one or more devices usedto transmit and receive data, such as a modem or a network adapter.Further, a memory may be, for example, memory 206 or a cache such asfound in an interface and memory controller hub that may be present incommunications fabric 202.

Computer program code for carrying out operations of the presentinvention may be written in any combination of one or more programminglanguages, including an object-oriented programming language such asJava™, Smalltalk, C++, C#, Objective-C, or the like, and conventionalprocedural programming languages. The program code may execute entirelyon the user's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer, or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Those of ordinary skill in the art will appreciate that the hardware inFIGS. 1-2 may vary depending on the implementation. Other internalhardware or peripheral devices, such as flash memory, equivalentnon-volatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIGS. 1-2. Also, theprocesses of the illustrative embodiments may be applied to amultiprocessor data processing system, other than the SMP systemmentioned previously, without departing from the spirit and scope of thedisclosed subject matter.

As will be seen, the techniques described herein may operate inconjunction within the standard client-server paradigm such asillustrated in FIG. 1 in which client machines communicate with anInternet-accessible Web-based portal executing on a set of one or moremachines. End users operate Internet-connectable devices (e.g., desktopcomputers, notebook computers, Internet-enabled mobile devices, or thelike) that are capable of accessing and interacting with the portal.Typically, each client or server machine is a data processing systemsuch as illustrated in FIG. 2 comprising hardware and software, andthese entities communicate with one another over a network, such as theInternet, an intranet, an extranet, a private network, or any othercommunications medium or link. A data processing system typicallyincludes one or more processors, an operating system, one or moreapplications, and one or more utilities. The applications on the dataprocessing system provide native support for Web services including,without limitation, support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL,among others. Information regarding SOAP, WSDL, UDDI and WSFL isavailable from the World Wide Web Consortium (W3C), which is responsiblefor developing and maintaining these standards; further informationregarding HTTP and XML is available from Internet Engineering Task Force(IETF). Familiarity with these standards is presumed.

Cloud Computing Model

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models, all as more particularly described anddefined in “Draft NIST Working Definition of Cloud Computing” by PeterMell and Tim Grance, dated Oct. 7, 2009.

In particular, the following are typical Characteristics:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported providing transparency for both theprovider and consumer of the utilized service.

The Service Models typically are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

The Deployment Models typically are as follows: Private cloud: the cloudinfrastructure is operated solely for an organization. It may be managedby the organization or a third party and may exist on-premises oroff-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service-oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes. A representative cloud computing nodeis as illustrated in FIG. 2 above. In particular, in a cloud computingnode there is a computer system/server, which is operational withnumerous other general purpose or special purpose computing systemenvironments or configurations. Examples of well-known computingsystems, environments, and/or configurations that may be suitable foruse with computer system/server include, but are not limited to,personal computer systems, server computer systems, thin clients, thickclients, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputer systems, mainframe computersystems, and distributed cloud computing environments that include anyof the above systems or devices, and the like. Computer system/servermay be described in the general context of computer system-executableinstructions, such as program modules, being executed by a computersystem. Generally, program modules may include routines, programs,objects, components, logic, data structures, and so on that performparticular tasks or implement particular abstract data types. Computersystem/server may be practiced in distributed cloud computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed cloudcomputing environment, program modules may be located in both local andremote computer system storage media including memory storage devices.

Referring now to FIG. 3, by way of additional background, a set offunctional abstraction layers provided by a cloud computing environmentis shown. It should be understood in advance that the components,layers, and functions shown in FIG. 3 are intended to be illustrativeonly and embodiments of the invention are not limited thereto. Asdepicted, the following layers and corresponding functions are provided:

Hardware and software layer 300 includes hardware and softwarecomponents. Examples of hardware components include mainframes, in oneexample IBM® zSeries® systems; RISC (Reduced Instruction Set Computer)architecture based servers, in one example IBM pSeries® systems; IBMxSeries® systems; IBM BladeCenter® systems; storage devices; networksand networking components. Examples of software components includenetwork application server software, in one example IBM WebSphere®application server software; and database software, in one example IBMDB2® database software. (IBM, zSeries, pSeries, xSeries, BladeCenter,WebSphere, and DB2 are trademarks of International Business MachinesCorporation registered in many jurisdictions worldwide)

Virtualization layer 302 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers;virtual storage; virtual networks, including virtual private networks;virtual applications and operating systems; and virtual clients.

In one example, management layer 304 may provide the functions describedbelow. Resource provisioning provides dynamic procurement of computingresources and other resources that are utilized to perform tasks withinthe cloud computing environment. Metering and Pricing provide costtracking as resources are utilized within the cloud computingenvironment, and billing or invoicing for consumption of theseresources. In one example, these resources may comprise applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal provides access to the cloud computing environment forconsumers and system administrators. Service level management providescloud computing resource allocation and management such that requiredservice levels are met. Service Level Agreement (SLA) planning andfulfillment provides pre-arrangement for, and procurement of, cloudcomputing resources for which a future requirement is anticipated inaccordance with an SLA.

Workloads layer 306 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation; software development and lifecycle management; virtualclassroom education delivery; data analytics processing; transactionprocessing; and others (e.g., enterprise-specific functions in a privatecloud).

It is understood in advance that although this disclosure includes adetailed description on cloud computing, implementation of the teachingsrecited herein are not limited to a cloud computing environment. Rather,embodiments of the present invention are capable of being implemented inconjunction with any other type of computing environment now known orlater developed.

Thus, a representative cloud computing environment has a set of highlevel functional components that include a front end identity manager, abusiness support services (BSS) function component, an operationalsupport services (OSS) function component, and the compute cloudcomponent. The identity manager is responsible for interfacing withrequesting clients to provide identity management, and this componentmay be implemented with one or more known systems, such as the TivoliFederated Identity Manager (TFIM) that is available from IBMCorporation, of Armonk, N.Y. In appropriate circumstances TFIM may beused to provide federated single sign-on (F-SSO) to other cloudcomponents. The business support services component provides certainadministrative functions, such as billing support. The operationalsupport services component is used to provide provisioning andmanagement of the other cloud components, such as virtual machine (VM)instances. A virtual machine is an operating system or applicationenvironment that is installed on software, but that imitates a hardwaremachine. The cloud component represents the main computationalresources, which are typically a plurality of virtual machine instancesthat are used to execute a target application that is being madeavailable for access via the cloud. One or more databases are used tostore directory, log, and other working data. All of these components(included the front end identity manager) are located “within” thecloud, but this is not a requirement. In an alternative embodiment, theidentity manager may be operated externally to the cloud. The serviceprovider also may be operated externally to the cloud.

Some clouds are based upon non-traditional IP networks. Thus, forexample, a cloud may be based upon two-tier CLOS-based networks withspecial single layer IP routing using hashes of MAC addresses. Thetechniques described herein may be used in such non-traditional clouds.

FIG. 4 illustrates a typical IT infrastructure that supportsvirtualization of resources and in which the below-described techniquesof this disclosure may be implemented. For purposes of explanation, theIT datacenter that provides shared (public) resources is the “provider”and a customer or company that uses these shared resources to host,store and manage its data and applications (in all forms) is the“subscriber” (or “customer” or “tenant”). In FIG. 4, an example virtualmachine hosting environment (alternately referred to herein as a datacenter or “cloud”) is illustrated. This environment comprises hostmachines (HVs) 402 (e.g., servers or like physical machine computingdevices) connected to a physical datacenter network 404, typically via ahypervisor management VLAN 406. Although not depicted explicitly,typically the environment also includes load balancers, network dataswitches (e.g., top-of-rack switches), firewalls, and the like. As shownin FIG. 4, physical servers 402 are each adapted to dynamically provideone or more virtual machines (VMs) 408 using virtualization technology.Such technology is available commercially, e.g., from VMware® or others.Server virtualization is a technique that is well-known in the art. Asdepicted, multiple VMs can be placed into a single host machine andshare the host machine's CPU, memory and other resources, therebyincreasing the utilization of an organization's data center. In thisenvironment, tenant applications 410 are hosted in network appliances412, and tenant data is stored in data stores and databases 414. Theapplications and data stores are connected to the physical datacenternetwork 404, typically via a network management/storage VLAN 416.Collectively, the virtual machines, applications and tenant datarepresent a subscriber-accessible virtualized resource management domain405. Through this domain, the subscriber's employees may access andmanage (using various role-based privileges) virtualized resources theyhave been allocated by the provider and that are backed by physical ITinfrastructure. The bottom portion of the infrastructure illustrates aprovider-accessible management domain 415. This domain comprises aprovider employee management portal 418, the BSS/OSS managementfunctions 420, various identity and access management functions 422, asecurity policy server 424, and management functions 426 to manage theserver images 428. These functions interface to the physical datacenternetwork via a management VLAN 430. The provider's employees havespecialized privileges (and perhaps specific clients/networks) fromwhich they have access to the Operational and Business Support Services(OSS/BSS) that they use to manage the IT datacenter infrastructure(e.g., hardware and software installations, configurations, monitoring,technical support, billing, and the like).

Generalizing, the cloud computing infrastructure provides for a virtualmachine hosting environment that comprises host machines (e.g., serversor like physical machine computing devices) connected via a network andone or more management servers. Typically, the physical servers are eachadapted to dynamically provide one or more virtual machines usingvirtualization technology, such as VMware ESX/ESXi. Multiple VMs can beplaced into a single host machine and share the host machine's CPU,memory and other resources, thereby increasing the utilization of anorganization's data center. Among other tasks, the management servermonitors the infrastructure and automatically manipulates the VMplacement as needed, e.g., by moving virtual machines between hosts.

In a non-limiting implementation, representative platform technologiesare, without limitation, IBM System x® servers with VMware vSphere 4.1Update 1 and 5.0.

It is also known in the art to configure or provision cloudarchitectures such as described above to include mechanisms and systemsthat operate generally to gather (or otherwise obtain from other datasources) information about available cloud platforms, topologies andcapabilities. Typically, cloud security may be implemented and enforcedwith various techniques that include, without limitation, virtualperimeter networks (DMZs), network segregation, storage isolation,Intrusion Prevention System (IPS) deployment, Security Information andEvent Management (SIEM) deployment, reverse proxies, firewalls, SSLcommunication, configuration with existing SIEM, multi-factorauthentication, risk-based authentication, and others.

An example security and management platform that provides real-timevisibility and control across endpoints, whether connected to the cloudor otherwise, is IBM® BigFix®. IBM BigFix, formerly IBM EndpointManager, Tivoli Endpoint Manager (TEM) and before that, BigFix, is asystems management software product for managing large groups ofcomputers running Windows, Mac, OS/X, VMware ESX, Linux or UNIX, as wellas various mobile operating systems such as Windows Phone, Symbian, iOSand Android. IBM BigFix provides system administrators with remotecontrol, patch management, software distribution, operating systemdeployment, network access protection and hardware and softwareinventory functionality. It addresses a major challenge faced by manyorganizations, namely, how to gain full visibility into the constantlychanging endpoint landscape while bridging the gap between threatdetection and remediation.

Cloud application packages may be deployed using platform-as-a-service(PaaS) infrastructure, such as the IBM® Cloud open cloud managementplatform (also known as SmartCloud® Orchestrator), or IBM® Bluemix™,which is an open-standards, cloud-based platform for building, managing,and running apps of all types, such as web, mobile, big data, and smartdevices. Bluemix capabilities include Java, mobile back-end development,and application monitoring, as well as features from ecosystem partnersand open source, all provided as-a-service in the cloud. Bluemixabstracts and hides most of the complexities that are associated withhosting and managing cloud-based applications. Bluemix is based on CloudFoundry open technology and runs on SoftLayer infrastructure. UsingBluemix, an application developer can focus on developing the cloudapplication without having to manage the infrastructure that is requiredto host it. For mobile apps, the developer can use pre-built servicesthat are provided by Bluemix. For web apps, the developer can upload theapplication to Bluemix and indicate how many instances to run. Then,Bluemix takes care of the deployment. After the apps are deployed, auser can easily scale them up or down when the usage or load of the appschange.

When the user creates an application and deploys it to Bluemix, theBluemix environment determines an appropriate virtual machine (VM) towhich the application or artifacts that the application represents issent. For a mobile application, a mobile back-end projection is createdon Bluemix. Any code for the mobile app running in the cloud eventuallyruns in the Bluemix environment. For a web app, the code running in thecloud is the application itself that the developer deploys to Bluemix.The determination of the VM is based on several factors, including: theload already on the machine, and runtimes or frameworks supported bythat VM. After a VM is chosen, an application manager on each VMinstalls the proper framework and runtime for the application. Then theapplication can be deployed into that framework.

The cloud computing environment may also include various deployment andmanagement tools. For example, IBM Cloud includes IBM® Cloud Managerwith OpenStack. Cloud Manager is a self-service portal for simplifiedcloud management for the cloud end user. Cloud Manager with OpenStackenables the user to work with virtual appliances and workloads focusingon the end user's perspective, rather than the IT or systemsadministrator's perspective. Self-service capabilities simplify theprocess of executing many common public or private cloud operations suchas provisioning and de-provisioning servers (process known asdeploying), drafting and cloning deployments, taking deploymentsnapshots, starting up and shutting down servers, and resizing existingservers.

Cloud management solutions of this type typically also provide the useran ability to create virtual machines using templates. For example, IBMCloud Manager with OpenStack includes VMware. VMware virtual machine(VM) template is a master copy of a virtual machine, and it is widelyused by VMware to create new virtual machines. The VMware driver of IBM®Cloud Manager with OpenStack allows the user to create instances from aVM template, and to create a VM template image from a running instance.

Virtual Desktop Infrastructure

As additional background, and as noted above, one common applicationclass that has been increasingly deployed in the cloud is desktopvirtualization implemented as a virtual desktop infrastructure (VDI).VDI typically provides a stateless thin client to the user while hostingthe processing and storage resource in a remote virtual machine. In thisenvironment, a core component is a cloud-supported (sometimes referredto herein as a “central”) VDI server that manages a pool of computers(physical or virtual). There may be multiple VDI servers in theinfrastructure. In one representative VDI environment, each user hastheir own virtual machine that runs on or in association with a VDIserver and is accessed and controlled using a given remote displayprotocol (RDP). A remote display protocol is a set of data transferrules that provide for a desktop hosted at the central VDI server todisplay on a client's screen at a remote location. Popular remotedisplay protocol technologies include VMware's PC over IP (PCoIP),Microsoft's RemoteFX and others. The virtual machines may be existingalready, or they may be spawned on-demand. The user (accessing from theremote location) has a device, such as a computer, a terminal orappliance, a mobile device, or the like), typically with a VDI clientinstalled. The client connects to the VDI server, which in turn affordsthe user remote access to a desktop of one of the computers in the pool.The user may then use one or more applications that are installed on themachine.

Generalizing, the VDI server is a desktop virtualization software thatallows multiple users to access and run desktops that are installed at acentralized location separate from the devices from which they are beingaccessed. A representative VDI server is Citrix® XenDesktop. It managesall the user sessions and corresponding virtual machines that are beingspawned to handle these sessions. Information about all events in theVDI environment (session start/end, VM spawn/destroy etc.) are stored inthe XenDesktop database and are then available for retrieval, eitherdirectly from the database or through an OData API. Both methods toaccess data require authentication. XenDesktop keeps historical data forseven (7) days by default.

Template-Based Software Discovery in a Virtual Desktop Infrastructure(VDI) Environment

With the above as background, the technique of this disclosure is nowdescribed. A representative VDI operating environment is shown in FIG.5, which depicts a computer system 500 comprising client devices 510,511, 512 connected via a communication network 520, 521, 522 to acomputing infrastructure 530. Computing infrastructure may beimplemented as described above in FIGS. 3 and 4. The client devices 510,511, 512 (such as depicted in FIG. 2) may comprise a notebook 510, atablet computer 511 or a fixed computer 512. The communication networkmay be a mobile communication network 520, e.g., an LTE network, a WIFInetwork 521 or an Ethernet (or other wired) network 522. A user may login to the computing infrastructure 530 via one of the client devices510, 511, 512, for example, via the client device 510. Typicalclient-server interaction in this context is depicted in FIG. 1. Thecomputing infrastructure (e.g., FIG. 4) comprises a hypervisor 540 forinstantiating a virtual machine 531 in response to the user 540 loggingin to the computing infrastructure. A remote desktop is provided to theclient device 510 such that the user may interact with the virtualmachine 531. Alternatively, a user logging in to the computinginfrastructure 530 may be connected to an already present instance of avirtual machine image. Typically, in a VDI environment such as shown,each user has their own virtual machine that runs on the VDI server 533and is accessed and controlled using a remote desktop protocol. Arepresentative VDI server is XenDesktop, as previously noted.

According to this disclosure, and in one embodiment, the cloud computingenvironment includes or has associated therewith a license managementsystem 550 that provides various application discovery, monitoring andmanagement functions, as are now described. The license managementsystem 550 typically is implemented as software (one or more computerprograms) executed in one or more hardware processors. The licensemanagement system 550 may be a standalone function or module, or acomponent of some other system, device, program or process.

As will be described, the license management system is configured todetermine “software application usage information,” which typicallyincludes information about the software applications that were madeavailable to the user from a virtual machine. One of many existingsoftware licensing models is that the software application usageinformation need not include particular details on the user's actualusage of any particular software application, but rather merely that thesoftware application was made available to the user during the session.Thus, preferably the license management system assumes an“install-based” metric of application licensing. In the preferredapproach herein, and as described below, all applications that areinstalled (i.e., available to the user) are counted as used by aparticular pair (namely, user and client device) over a particular timeperiod (e.g., a day) if the user has a VDI session during that timeperiod connecting from the client device. While the install-based metricis preferred, in an appropriate circumstance, the software applicationusage information may include particular use information.

The license management system 550 (sometimes referred to herein as alicense manager) provides for VM template-based software and discoveryand management in the VDI environment, as is now described. Oneembodiment involves a common use scenario in which a new VM isinstantiated when a new user session is created and then destroyed atsession end. In this embodiment, the license manager 550 preferably isconfigured to retrieve session information about a user logged in to thecomputing infrastructure 530 via the client device 510. The time a useris logged in to the computing infrastructure 530 typically is a session.As used herein, a “session” corresponds to a period of uninterruptedactivity of the user accessing a remote desktop. The session informationmay include various data such as one or more of: start date and time ofthe session, end date and time of the session, user identificationassociated with the session, and/or client device identification of theclient device. In this embodiment, which is non-limiting, instantiationof the virtual machine for the user corresponds with user session start,and a particular user session with a VDI VM may also be described hereinas a “virtual desktop connection.”

The license manager 550 is further configured to receive or to determinea list of software applications available in a virtual machine template,which is sometimes referred to herein as an “image.” This is sometimesreferred to herein as “software discovery.” Typically, every virtualmachine instance based on the virtual machine image allows a user to useany software application available in the virtual machine image. Thelist of software applications can be obtained in various ways dependingon the underlying cloud computing implementation, e.g., in a BigFiximplementation the license management system interacts (e.g., via arequest-response protocol, inter-process communication, or the like)with BigFix Inventory, which provides the software discoveryfunctionality. In the alternative, the license management system mayimplement this function natively. Another approach is to simply manuallycreate the list of the software present in the virtual machine image.Typically, the list is a text file with application names and versions.Generalizing, the list can be obtained automatically, programmatically,manually or the like, by scanning single virtual machines created fromthe template, by creating lists of program names manually, etc.

Thus, and according to this disclosure, a list of software installed ona virtual machine template (used to spawn virtual machines for users) isobtained. The software list is then associated with a history of virtualdesktop connections that is maintained, for example, in a database ofthe VDI server. This association enables monitoring of software licenseconsumption. As noted above, preferably software application usage datais determined as an “install-based” metric. This notion of applicationlicensing means that all applications that are installed (i.e. availableto the user are counted as used by a particular user/client device pairover a time period of interest if there is virtual desktop connection(i.e. the user has a VDI session in that time period connecting from theclient device). In one embodiment, the number of VMs does not count forapplication licensing purposes; rather, what is counted is a number ofpairs <user><client device> that access the VDI infrastructure, andwherein the client device may be of any type. Thus, for example, if auser U1 connects to VDI from two different terminals T1 and T2,preferably the license manager counts this access as two license usages.If users U1 and U2 connect to VDI from the same terminal T1, it alsocounts as two usages. If user U1 connects from terminal T1 and user U2connects from terminal T2, it is still two usages, irrespective of howmany VMs handled these sessions.

FIG. 6 is a process flow detailing the above-described operation of thelicense manager. To this end, the license manager routine begins at step600 by preparing a list of software installed on the VM template (a“first list”). Preferably there is a separate first list for every VMtemplate. At step 602, the license manager obtains from the VDI server(or other cloud resource that has the information) a second list,namely, a list of virtual desktop connections for a particular timeperiod. In one embodiment (e.g., where the VDI server is XenDesktop oran equivalent) a virtual desktop connection entry in the second listtypically is defined by the following information: when the connectionstarted, when the connection ended, a network or other address of thedevice that is connecting to a virtual desktop, a name or otheridentifier for the user, and an identification of the template that wasused to spawn the VM for the connection. At step 604, the informationobtained in steps 600 and 602 is combined to create software applicationusage information for the desired time period In particular, for everyconnection read from the VDI server, the routine identifies the VMtemplate used to create the VM to which the user is connected; then, andfor every application present on the list of software installed on thisparticular VM template, the license usage information (typically theusage count, as noted above) is generated. As noted, the license usageinformation typically comprises: application identification (obtainedfrom the VM template software list), start date and time (obtained fromthe VDI server connection information), end data and time (obtained fromthe VDI server connection information), user identification (obtainedfrom the VDI server connection information), and terminal deviceidentification (obtained from the VDI server connection information).This completes the discovery process.

At step 606, the software application usage information is then providedto one or more other systems, sub-systems, programs or processes withinor otherwise associated with the cloud computing environment. Thus, forexample, the data is used for reporting and (with user- orsystem-defined thresholds) to notify interested persons, entities orsystems about usage that exceeds a license quota or that is about toexceed the quota. The information may be provided to an inventorymanagement or accounting system. The information may be provided to asecurity or compliance policy system that implements or facilitatesmitigation or remediation of an over usage, e.g., when the licensemanager counts reflect that usage may deny service to another tenant.The information may be provided to other systems, e.g., to facilitateVDI or cloud computing infrastructure administration, maintenance,operations or otherwise.

In the above-described embodiment, the connection start and end timesare sufficient because they represent the information that the licensemanager needs, namely, the uninterrupted activity of the user accessingthe remote desktop (because only then are the installed applicationsavailable to the user). Thus, in the usual case the license manager usesconnection start and end timestamps for reporting application usage forthe “session.” That said, in some VDI server environments if aconnection end timestamp is unknown for any reason (e.g., because theuser disconnects and reconnects a remote desktop session without loggingout), the connection information may be amended or supplanted with otherinformation, such as an end timestamp taken from the session to whichthe connection belongs.

The subject matter herein provides significant advantages. The approachherein enables a service provider to monitor license usage for softwarein a VDI environment. Traditional approaches to monitoring license usagein this context (e.g., installing a program on a machine that scansinstalled software and monitors running processes) are not useful in theVDI environment, wherein virtual machine lifetime is often too short toperform such scans. The license manager overcomes the shortcomings ofthese prior art approaches and provides for accurate install-basedmetrics for application licensing. The license manager provides thisadvantage by counting all applications that are installed (i.e.,available to the user) as used by a particular pair (namely, user andclient device) over a particular time period (e.g., a day) if the userhas a VDI session during that time period connecting from the clientdevice. By accounting for software usage in this manner, the approachherein enables the cloud provider to accurately track, manage, audit,and account for software usage in the VDI environment.

The license management system (or any component thereof) may be part ofsome other system (e.g., an inventory or log management solution), orpart of other cloud management or security architecture. The licensemanager may be implemented as a solution, service, product, appliance,device, process, program, one or more execution threads, or the like.Typically, and as noted, the techniques are implemented in software, asone or more computer programs executed in hardware processing elements,in association with data stored in one or more data sources. Some or allof the processing steps described may be automated and operateautonomously in association with other systems. The automation may befull- or partial, and the operations (in whole or in part) may besynchronous or asynchronous, demand-based, or otherwise.

Without limitation, the license manager (as a product or service) may beimplemented within or in association with a cloud platform system orappliance (FIG. 4) as has been described, or using any other type ofdeployment systems, products, devices, programs or processes. Aspreviously noted, the above-described components typically are eachimplemented as software, i.e., as a set of computer program instructionsexecuted in one or more hardware processors. The components are shown asdistinct, but this is not a requirement, as the components may also beintegrated with one another in whole or in part. One or more of thecomponents may execute in a dedicated location, or remote from oneanother. One or more of the components may have sub-components thatexecute together to provide the functionality. There is no requirementthat particular functions of the license management system product orservice be executed by a particular component as named above, as thefunctionality herein (or any aspect thereof) may be implemented in otheror systems. In addition, the nature of the particular licensing schemebeing enforced by the license management system is not a particularrequirement.

The license manager may be implemented by a cloud service provider thatoperates infrastructure for a private cloud, a public cloud, or a hybridcloud. It may be available as a managed service provided by a cloudservice or some other service provider.

There may be alternative embodiments. The system may be separated intomultiple sub-systems, which then work together or cooperatively. Forexample, instead of having a single license management system for theentire infrastructure, there may be several of such systems, perhaps onefor each of the tenants (or tenant types) in the infrastructure. Eachsystem (or sub-system, as the case may be) may then feed the informationto a master system, which generates the desired results.

The techniques herein may be extended to other cloud models includingPaaS and IaaS.

As described, the approach herein may be implemented manually or in anautomated manner, in whole or in part.

While a preferred operating environment and use case (a cloud applianceor platform) has been described, the techniques herein may be used inany other operating environments. The approach may be integrated in aVDI server, or the like.

As has been described, the functionality described above may beimplemented as a standalone approach, e.g., one or more software-basedfunctions executed by one or more hardware processors, or it may beavailable as a managed service (including as a web service via aSOAP/XML interface). The particular hardware and software implementationdetails described herein are merely for illustrative purposes are notmeant to limit the scope of the described subject matter.

More generally, computing devices within the context of the disclosedsubject matter are each a data processing system (such as shown in FIG.2) comprising hardware and software, and these entities communicate withone another over a network, such as the Internet, an intranet, anextranet, a private network, or any other communications medium or link.The applications on the data processing system provide native supportfor Web and other known services and protocols including, withoutlimitation, support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, andWSFL, among others. Information regarding SOAP, WSDL, UDDI and WSFL isavailable from the World Wide Web Consortium (W3C), which is responsiblefor developing and maintaining these standards; further informationregarding HTTP, FTP, SMTP and XML is available from Internet EngineeringTask Force (IETF).

In addition to the cloud-based environment, the techniques describedherein may be implemented in or in conjunction with various server-sidearchitectures including simple n-tier architectures, web portals,federated systems, and the like.

Still more generally, the subject matter described herein can take theform of an entirely hardware embodiment, an entirely software embodimentor an embodiment containing both hardware and software elements. In apreferred embodiment, the security assurance service (or any componentthereof) is implemented in software, which includes but is not limitedto firmware, resident software, microcode, and the like. Furthermore,the download and delete interfaces and functionality can take the formof a computer program product accessible from a computer-usable orcomputer-readable medium providing program code for use by or inconnection with a computer or any instruction execution system. For thepurposes of this description, a computer-usable or computer readablemedium can be any apparatus that can contain or store the program foruse by or in connection with the instruction execution system,apparatus, or device. The medium can be an electronic, magnetic,optical, electromagnetic, infrared, or a semiconductor system (orapparatus or device). Examples of a computer-readable medium include asemiconductor or solid state memory, magnetic tape, a removable computerdiskette, a random access memory (RAM), a read-only memory (ROM), arigid magnetic disk and an optical disk. Current examples of opticaldisks include compact disk-read only memory (CD-ROM), compactdisk-read/write (CD-R/W) and DVD. The computer-readable medium is atangible, non-transitory item.

In a representative embodiment, the techniques are implemented in aspecial purpose computing platform, preferably in software executed byone or more processors. The software is maintained in one or more datastores or memories associated with the one or more processors, and thesoftware may be implemented as one or more computer programs.Collectively, this special-purpose hardware and software comprises thefunctionality described above.

In the preferred embodiment as described above, the functionalityprovided herein is implemented as an adjunct or extension to an existingcloud compute VDI solution.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

Finally, while given components of the system have been describedseparately, one of ordinary skill will appreciate that some of thefunctions may be combined or shared in given instructions, programsequences, code portions, and the like.

The techniques herein provide for improvements to another technology ortechnical field, namely, software license management solutions and cloudcomputing environments, as well as improvements to the functioning ofrelated inventory management facilities and systems.

As noted, unless otherwise specified, the nature, type and semantics ofthe software application usage data and what that data is used for(e.g., auditing, compliance, etc.) is not a limitation of thisdisclosure.

The identification of any commercial product herein is not intended tolimit the scope of the subject matter.

While the license manager preferably enforces an “install-based”licensing model, it may also be used with other models including,without limitation, “usage-based,” wherein the actual usage of theapplication is what is counted, “hardware-based,” wherein license costis based on the hardware specifications on which the software runs,combinations thereof, and the like. Further, the license manager may beconfigured to count licenses against users only, without reference tothe client devices they use. In this latter scenario (counting licensesper users), there may additional variations, e.g., “named users”(wherein every user of the software application must be uniquelyidentified and the total number of possible users of the software iswhat is counted), “concurrent users,” (wherein a maximum numbers ofusers accessing the software application at a given time is what iscounted), and so forth.

Having described our invention, what we claim is as follows.

1. A method for license management in a computing infrastructurecomprising a server that manages a pool of virtual machines, comprising:receiving first information identifying one or more softwareapplications associated with a virtual machine template used in thevirtual desktop infrastructure; receiving second information that a userhas logged into the virtual desktop infrastructure from a client device,thereby creating a session, the session being associated with a virtualmachine template; for a particular time period, calculating softwareapplication usage information from the first and second information,wherein the software application usage information is associated with alicensing model that defines a usage metric based at least in part onthe user having the session during at least some portion of the timeperiod; and providing the software application usage information toanother computing system to take a given action.
 2. The method asdescribed in claim 1 wherein the computing infrastructure is a virtualdesktop infrastructure (VDI).
 3. The method as described in claim 2wherein the server is a VDI server and the second information representsa virtual desktop connection between the client device and the VDIserver.
 4. The method as described in claim 2 wherein the session is aVDI session and the second information comprises one of: start date andtime of the VDI session, end date and time of the VDI session, anidentification of the user associated with the VDI session, and anidentification of the client device.
 5. The method as described in claim2 wherein the given action is one of: tracking, managing, auditing,enforcing and accounting for software usage in the VDI environment. 6.The method as described in claim 1 wherein the second informationidentifies a client device that is a stateless thin client.
 7. Themethod as described in claim 6 further including spawning a virtualmachine from the virtual machine template to provide a virtual desktopfor the user of the client device.